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Aspect-orientation is a relatively new paradigm that introduces abstractions to modularize the imple- 
mentation of system-wide policies. It is based on a composition operation, called aspect weaving, 
that implicitly modifies a base system by performing related changes within the system modules. 
Aspect-oriented graph grammars (AOGG) extend the classic graph grammar formalism by defining 
aspects as sets of rule-based modifications over a base graph grammar. Despite the advantages of 
aspect-oriented concepts regarding modularity, the implicit nature of the aspect weaving operation 
may also introduce issues when reasoning about the system behavior. Since in AOGGs aspect weav- 
ing is characterized by means of rule-based rewriting, we can overcome these problems by using 
known analysis techniques from the graph transformation literature to study aspect composition. In 
this paper, we present a case study of a distributed client-server system with global policies, mod- 
eled as an aspect-oriented graph grammar, and discuss how to use the AGG tool to identify potential 
conflicts in aspect weaving. 

1 Introduction 

Aspect-oriented programming ifTTTl is a relatively new paradigm which introduces abstractions to modu- 
larize the implementation of system-wide policies. It is based on a composition operation, called aspect 
weaving, that modifies a base system globally according to structural rules such as, for instance, "register 
in a global log all modifications in the value of the field x of class C". As characterized in Q, an aspect 
is a module that i) identifies in other modules sets of execution points, which are called pointcuts, and ii) 
define transformation rules associated with pointcuts. Those rules are called advices. Given a pointcut 
language expressive enough, the implementation of global policies becomes modular and consistent as 
the system evolves, i.e. new modules will abide by the global policy in the same way as the current ones. 

Those advantages stimulated the adoption of aspect-oriented programming in software development. 
Several languages now have aspect-oriented extensions, the most popular being the Java superset As- 
pect! [10]. Moreover, the usage of AOP-related concepts also started to appear in languages for system 
modeling, such as UML diagrams 0. However, the wide usage of aspect-oriented concepts also intro- 
duces issues in the software development process. The implicit modifications caused by aspect weaving 
may result in behaviors which are difficult to identify by source code analysis. Also, when the system 
has more than one aspect they may interfere with each other, resulting in different final systems accord- 
ing to the order they are combined. To deal with those problems, the developer needs proper models to 
reason consistently about the aspect influence. On the formal side, several aspect-oriented calculi have 
been proposed to characterize aspect interference over programming languages lfl6l [HI IS SI- On the 
implementation side, integrated development environments offer support to new views related to aspect 
weaving JT). However, outside the scope of source-code level aspects, there are still few models and 
techniques available to reason about aspect-oriented diagrams. 
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The current proposals for studying aspect weaving over diagrams have a strong connection with 
graph transformation systems and graph grammars, models where the system state is represented by a 
graph, and its execution, by the application of graph rewriting rules. Given the natural representation of 
diagrams as graphs, both aspect-oriented systems and graph transformation systems share some common 
characteristics: pointcuts resemble matches for graph rules, and advices resemble graph rules themselves. 
In lfl3l . aspect-oriented graph grammars (AOGGs) were proposed as an extension of the traditional graph 
grammars, where aspects were modeled as second-order transformations over the original specification. 
The advantage of this approach is that the same rewriting mechanism is used for both aspect weaving 
and base system execution, allowing to relate them formally. However, up to now it was not shown 
how to reason about AOGG models. In this work, we propose the use of AGG [2], an attributed graph 
grammar specification and analysis tool to reason about AOGG models. Since AGG does not support 
directly AOGGs, we propose an encoding procedure to convert graph grammar specifications into a 
single typed graph, with aspects being modeled as sets of graph rewriting rules. Then, we use the 
analysis functionalities of AGG to study conflicts between advices and aspects in the encoded AOGG 
system. 

The text is organized as follows: in Section |2l we review the graph grammar model, and introduce 
the base client-server example. In Section |3l we recall aspect-oriented graph grammars and present 
examples of aspects over the base system. In Section [4] we present the encoding of AOGGs as typed 
graphs in order to use the AGG tool. We discuss the use of critical pair analysis to study the aspect 
weaving in the encoded system in Section [5] Final remarks, related work and future steps are discussed 
in Section [6] 

2 Graph Grammars 

A typed graph grammar is a visual model where the system state is represented by a graph and the 
system behavior is described by means of rule-based graph rewriting. Formally, a typed graph grammar 
is a tuple (T, Go,P, 7l), where i) J is a type graph defining the allowed kinds of nodes and edges within the 
specification; ii) the T-typed graph Go is the initial state of the system; Hi) P is a set of rule names, and iv) 
the function % : P — > Rules{T) maps every rule name to is respective T-typed graph transformation rule. 
In this work we follow the double-pushout (DPO) approach to graph transformation [6], where a graph 
transformation rule is represented as a monic span (a pair of injective morphisms with the same source) 

/ r 

L^K^Rm the category T-Graph (J-typed graphs and type-preserving graph homomorphisms). The 
left-hand side (LHS) graph L represents the pattern to be found in order to apply the rule. The right-hand 
side (RHS) graph R defines new graph elements to be added by the rule. The interface graph K and graph 
inclusions / and r identify elements in L and R. Elements in L but not in l(K) are said to be deleted, 
elements in R but not in r(K) are said to be created, and elements in K are preserved or read. 

Example 1 (Graph grammar). Figure [7] depicts a distributed client-server system modeled as a graph 
grammar. The type graph T defines four kinds of nodes ( Client, Server, Data and Message) and four 
kinds of edges. The initial graph Go defines the initial state of the system: two clients with messages to 
be sent and two data servers. Clients may retrieve values from servers or update stored data by means 
of message exchange. The system rules model this interaction as follows: a GET message is sent to 
the server by SendGET, then the data is retrieved by ExecuteGET, and it is returned to the client by 
ReceiveGET. The rules SendSET, ExecuteSET and ReceiveSET work in a similar way for messages 
that update data elements. Regarding the notation, rules are presented only by their left-hand side and 
right-hand side graphs. Common elements in K are simply marked to be the same in L and R using 
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numbered prefixes ( 1 :, 2 :, . . . ). It is also important to notice that this example uses attributed graph 
nodes, which is an extension of the basic typed graph grammar formalism. 

In order to apply a graph transformation rule L <— K — > R over a graph G it is required that there is 
some match in G for elements of L. Matches are defined as graph homomorphism m : L — > G. Then, a rule 
application (or direct derivation) from graph G to graph H using rule r and match m (denoted G =4> H) 
is defined as the following diagram in the category T-Graph, where both squares are pushouts. 



<K> *■ R 



(l) k 



(2) 



G -e— D # 

Z r 

/* k 

In the DPO approach, rule application relies on finding G <— D <— K such that the square to the left is 
a pushout. This may not always be possible depending on the rule and match. For instance, when the 
rule tries to delete a node that has incident edges not in m(L), or when the match identifies preserved 
elements with deleted ones. 

The sequential behavior of a graph grammar is given by the successive application of graph rules 
starting from the initial graph. Usually, both rules and matches are nondeterministically chosen at each 
step. Operationally, this works as follows: 

1 . Set Go as the current graph. 

2. Find in the current graph all possible matches for rules in the set P of rule names. 

3. Verify application conditions for matches, defining the set of valid pairs (rule,match). 

4. If there is no valid pair at all, then STOP. Otherwise, non-deterministically choose a pair 
(rule,match) to be applied. 

5. Delete from G all matched elements in L \ K. This will generate a graph D. 

6. Create in D all elements in R \ K. This will generate a graph H. 

7. Set H as the current graph. Return to step 2. 

Graph grammars are particularly useful to represent distributed systems since graph rules represent 
local transformations. This means that two or more rules may be applied in parallel if they do not conflict 
with each other. Moreover, the rules are usually intuitive and the control flow is data-driven, being guided 
by the graph topology. 

The AGG tool [2] allows to create, run and analyze graph grammars. Moreover, it supports several 
extensions to the basic typed graph grammar language, such as attributed graph elements, control flow 
mechanisms (rule layers, priorities), definition of positive and negative application conditions for rules, 
among others. The AGG graph transformation engine follows the single-pushout (SPO) approach 021, 
but it may also be configured to consider the conditions that characterize DPO transformations. 



3 Aspect-Oriented Graph Grammars 



Aspect-Oriented Graph Grammars (AOGGs) |[T3l are graph grammars with aspects, i.e. modular de- 
scriptions of system-wide policies. Formally, an AOGG is a pair (5f,A), where £f = {T,Go,P,7i) is a 
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base graph grammar, and A = [A\ , A2, . . . ,A n ] is a sequence of graph aspects over £f. A graph aspect rep- 
resents a set of modifications over the base graph grammar, and it is defined by a triple (D,t,g), where 
D is a set of graph advices, t : T T' is an extension of the original type graph and g : Go » G' is an 
extension of the original initial graph. 

Graph advices are rules that modify graph transformation rules. Following the intuition provided by 
the DPO approach, graph advices are defined as monic spans p <— < i >— > e. The difference is that p,i,e are 
themselves graph rules, and /, r are rule morphisms. Rule morphisms are defined as triples of morphisms 
connecting the graph components of two rules, respecting the commutativity of the inner squares. This 
way, a graph advice correspond to the following commutative diagram in T-Graph. 




To emphasize the distinction between advices and base system rules, the components of a graph 
advice receive specific names: pointcut p, advice interface i and effect e. 

Example 2 (Log Aspect). Suppose we want to implement a logging mechanism over the client-server 
system such that every operation leaves an execution trace over a global object ( the system logger). To 
implement this functionality, we should extend the type graph to introduce the logger type, initialize it in 
the initial graph and modify all rules to register their execution in this global object. Using AOGG, all 
these modifications can be enclosed within one single aspect, as shown in Figure\2\ This aspect has only 
one advice, which has an empty pointcut. The advice adds a Logger object to both the LHS and RHS of 
the rule such that the occurrence on the RHS has the rule name appended to the story string. Notice 
that this value update depends on the existence of a reflective operation rulename () which provides the 
name of the rule being executed. The empty pointcut matches all possible rules of the specification, thus 
after aspect weaving all of them will read and update the global log object. 
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Figure 2: Log aspect 



Example 3 (Security Aspect). Another kind of system-wide modification is the introduction of access 
control for servers. A simple implementation is to define two kinds of permissions for clients: Read and 
Write. Those permissions, represented as endoarcs in client nodes, affect message exchanges. A "SET" 
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message may only be sent by a user with write privileges, while a "GET" message, only by a user with 
read privileges. The aspect depicted in Figure\3\implements this policy over the base graph grammar of 
Example [7] The act of sending a message of a given kind ( SET or GET) defines the pattern used in the 
pointcuts of both advices. The effect is to augment the rules such that they require the respective user 
permissions to be read in order to execute. In both advices the interface i is the same as the pointcut p. 
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Figure 3: Security aspect 

As with graph rewriting, rule rewriting (advice application) is also defined as a double-pushout di- 
agram. The difference is that it uses the category P-MSpan of P-typed rules and rule morphisms 021. 
Given a graph grammar Sf = (T,Go,P,7l) and a graph aspect (D,t,g) over < S, with t : T —> T' and 
g : Go — > G' , the result of weaving A and is the graph grammar ( S' = (T' ,G' ,P' ,7i'). The rule set 
(P', %') is calculated based on (P, n) as the least set of rules such that 

1. If a rule in (P, n) is not matched by any advice in A, them the rule is kept unchanged in (P', n'). 

2. If a rule is matched by at least one advice in A, all the results of one-step rewritings (considering 
all possible advices and matchings) become elements of (P', n 1 ). In this case, the original rule does 
not appear in (P', %'). 

This definition for aspect weaving makes advice rewriting non-reentrant, i.e. a given rule may not be 
modified more than once per advice and match. This assures termination for the weaving process, even 
for advices that do not delete elements from rules. Finally, the semantics of an AOGG (^,A) is given 
by its respective weaved graph grammar 5f$, defined as the result of weaving all aspects of A over <$ in 
their respective order. 
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4 Encoding AOGGs in AGG 

The use of graph rewriting as an aspect weaving mechanism opens the possibility of using known tech- 
niques from the graph transformation area to reason about aspects. Those techniques allow the system 
modeler to identify potentially harmful behaviors of the final weaved system, such as unintended aspect 
interactions, at early stages of the system development. Furthermore, existing tools such as AGG can be 
used to analyze aspect-oriented models. 

Our approach consists in encoding the whole structure of a graph grammar specification as a sin- 
gle typed graph. For this, a representation of monic spans using graph elements is needed to encode 
individual rules. Moreover, one needs to encode both initial graph and rule set while keeping their as 
distinguished elements of the specification. For this, we employ the traditional graph typing mechanism: 
the type graph for the encoding of = (T, Go,P, Tt) has two disjoint components. The first is the original 
type graph T, used to type the initial graph Go. The second is R(T), used to type the encoded represen- 
tation of the rule set. We start by defining the operation R that calculates the second component based on 
the original type graph T. 

Definition 1 (Type graph rule encoding). The operation R : Graph — > Graph is defined as the composi- 
tion Rt, oR 2 oR\, where: 

• R\ encodes edges as nodes. The edges of the resulting graph follow the source and target functions 
of the input graph. 

• 7?2 creates three copies of the input graph (to represent L, K and R). Each node in K is connected 
to its copy in L and R by means of new edges. 

• 7?3 creates a new node in the graph together with edges connecting all the original nodes to this 
node. This node represents the identity of the rule. 

Example 4 (Type graph rule encoding). Figure^shows how to obtain R(T)from a simple type graph T 
using the successive transformations R\, R 2 and R3. 
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Figure 4: Example of type graph rule encoding. 



Now we define the operation S, which encodes T-typed rules as 7?(r)-typed graphs. 

Definition 2 (Graph rule encoding). Given a T -typed graph rule r:L-k—K^R, the graph rule encoding 
S : Rules(T) — > R(T)-Graph is defined as the composition S3 0S20S1, where 
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• Si applies 7?i to L,K,R, and types them, respectively, over the left, central and right embeddings 
qfR!(T)inR(T). 

• S2 adds concrete edges to the input graph following the homomorphisms I and r. 

• S3 creates a new node typed over the node created by transformation R3, together with new edges 
connecting all nodes of the input graph to it. 

Definition 3 (Graph rule set encoding). Given a graph grammar <$ = (T, Gq,P, 71), the R(T)-typed graph 
Y(Sf) is defined as the gluing [S(n(ri)),S(n(r2)), ■ . ■ ,S(lc(r n ))] where r\ .„ € P. 

The graph Y(Sf ) is the union of all encodings of rules S(n(r x )) typed over the single type graph R(T). 

Example 5 (Graph rule set encoding). Figure\5\depicts a small graph grammar & (on the left) and its 
respective R(T)-typed encoding Y(Sf ) (on the right). 




Figure 5: Example of graph rule set encoding. 



Definition 4 (Encoded graph grammar). Given a graph grammar <S = (T, Go,P, 7c), its graph encoding is 
the (T + R(T))-typed graph \S\ = Gq + Y^), where "+" stands for the disjoint union of typed graphs. 

Definition 5 (Encoded advice). Let A = (D,t,g) be and aspect over <S, such that t : T — > T'. Then, for 
every advice a : p <— i — > e G D, its respective encoding \a\ is the R(T')-typed span S(p) ^— S(i) — > S(e). 

Definition 6 (Encoded aspect-oriented graph grammar). Let 3? = (& ,A) be an AOGG, such that 
& = (T, Go,P, 7t) and A = [A\ ,A2, • ■ . ,A n ]. Let @A = (T—,G^,,P—, 71^) be the weaved graph grammar 
obtained from weaving A over ( S. Then, the encoded aspect-oriented graph grammar \3>\ is the graph 
grammar (7$ +R(T~), \@'\, \P\\, |^a|) where = (T^,G^,P, It) is the type and initial graph extension 
of^ and the rule set (\Pa\, \^a\) correspond to the gluing of all encoded advices \a\ G D,- of all aspects 
Ai = (D h t h gi), l<i<n. 

In an AOGG each aspect extend the type graph and initial graph of the original system. In the 
encoded graph \@\, all these extensions must be present in order to accommodate all encoded advices 
(of all aspects) in the same rule set. 

Example 6 (Encoded AOGG). Figure^shows the encoding of(&, [A\ ,A2\), where & is the base system 
of Figure \l\ A\ is the log aspect (Figure^ and A2 is the security aspect (Figure [?]). For the sake of 
readability, some elements are omitted: attribute types in the type graph and attribute values in the 
initial graph and base system rules. However, attribute values are shown in the encoded advices. In all 
encoded advices the interface graph K and the left-hand side graph L are the same. 
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Figure 6: Encoded client-server system with log and security aspects. 
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5 Analyzing AOGG specifications 

From the point of view of aspect weaving, it is relevant to be able to predict when two different advices 
will potentially affect the same part of the specification. If this occurs, a different aspect ordering may 
yield a different weaved system. Given that we encode an AOGG specification as a graph grammar, 
we are able to apply techniques from graph rewriting theory to test the existence of conflicts between 
aspects. 

Critical pair analysis (CPA) is a static analysis technique that is used to detect both conflicts and 
dependencies between graph rewriting rules. Given a graph G and two direct derivations G G', 
G =P G" , we say that the derivations are in conflict if one of them deletes some graph element that 
is preserved or deleted by the other one. Thus, their execution in parallel is not possible. Given two 
subsequent direct derivations G =^=S> G' G", we say that there is a dependency between {r\,m{) and 
(r2,ra2) if the first creates a graph element that is preserved or deleted by the later. In this case, it is 
not possible to swap their order of execution. Critical pair analysis is used to test potential conflicts and 
dependencies within a graph grammar and consists of the following general steps: 

1. The set of all pairs of rules (ri , 7-2) G P x P is generated. 

2. For each pair (n,^), all possible overlaps between a graph of r\ and a graph of ri are calcu- 
lated. In the case of conflict analysis, both LHSs are considered in this calculation. In the case of 
dependencies analysis, the RHS of r\ and the LHS of r2 are considered. 

3. All overlaps are tested for conflicts or dependencies. 

4. The number of all conflicting (or dependent) overlaps for each pair of rules is shown in a table. 
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Figure 7: Critical pair analysis of the base system in AGG. 

Aspect-oriented graph grammars are two-layer specifications where the base graph grammar de- 
scribe the original system behavior, while aspects describe the implementation of global policies as 
model transformation. By using the encoding of Section 4, we can use AGG to study characteris- 
tics of aspect weaving in a similar way as the original system execution. Figure [7] shows the results 
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of critical pair analysis for the base graph grammar. In this level, conflicts arise only in the pair 
(ExecuteSet,ExecuteGET) when the first rule updates a value which is read by the second one. De- 
pendencies reflect Send-Execute-Receive sequences of derivations, induced by the value of the Type 
attribute in message nodes. In the aspect level we analyze the possibility of conflicts in the aspect weav- 
ing process, since the rules are actually encoded advices. Figure [8] shows the results of CPA for the 
encoded model of Figure (6[ In this particular system, where the advices do not delete elements from 
rules, the rules are obviously conflict-free. Lack of conflicts in the aspect level means that final weaved 
system does not change even if we change the order aspects are weaved to the base system. If there was 
at least one conflicting pair of encoded advices (a 1,02) where a\ and aj are not in the same aspect, then 
the aspects could potentially interact and aspect weaving would not be necessarily a confluent operation. 
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Figure 8: Critical pair analysis of the aspect-oriented encoded system in AGG. 



6 Final remarks 

This work proposed the use of AOGG to model distributed system with aspects, and also the use of the 
AGG tool to study their behavior. We introduced the AOGG model, described an encoding mechanism to 
describe the base system as a single typed graph, and discussed the use of critical pair analysis to reason 
about conflicts in the aspect weaving operation. 

The idea of using graph rewriting to define aspect weaving is not entirely new. In lfl4l [171 . aspect 
weaving is also defined by means of graph rewriting, and the AGG tool is used to analyze the specification 
using critical pair analysis. In those approaches, however, UML diagrams are used as base system model. 
Following a different direction, the work by Aksit et al. encodes a complete aspect-oriented calculus 
into the graph transformation tool Groove 1131 . This allows to study the interference between aspects 
directly in the system unfolding, by employing the space-state generation feature of Groove. 

As future work, we intend to explore the properties of the proposed encoding. This is required in 
order to relate the behavior of the weaved system to the behavior of the original base system together 
with aspect specification. Furthermore, the usage of graph grammars as base systems may provide 
insights about how rule-base modification of rules affect the respective rule derivations, since both are 
representable as diagrams within the same categorical framework. 
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